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Abstract 


This  paoer  reviews  and  analyzes  the  desirable  properties  of 
a  computer  network  taxonomy  from  the  point  of  view  of  its  useful** 
ness  in  a  design  procedure.  A  key  factor  that  must  be  considered 
is  that  the  design  environment  currently  evolving  uses  function¬ 
ally  high  level  VLSI-based  building  blocks  to  construct  various 
network  architectures.  This  paoer  begins  by  reviewing  the  uses 
of  a  taxonomy  in  a  network  context,  and  continues  with  a  review 
of  specifications  for  network  requirements.  A  set  of  hardware 
interconnection  primitives  is  defined  next.  A  review  of  the 
Anderson  and  Jensen  taxonomy  (Ander75)  is  then  presented,  with  a 
discussion  of  its  completeness.  The  main  thrust  of  this  article 
is  given  in  a  section  on  attributes  of  a  design  oriented  taxon¬ 
omy.  Finally,  extensions  are  proposed  for  fault  tolerant  con¬ 
siderations  and  protocols. 

A  computer  network  is  defined  to  be  a  hetrogeneous  collec¬ 
tion  of  computers  and  the  telecommunic  tions  subsystem  linking 
them  together.  Here  the  properties  of  the  various  network  archi¬ 
tectures  are  of  particular  interest;  the  "user"  computers  (or 
processors)  are  considered  as  sources  and  sinks  of  messages  being 
transmitted  over  the  network.  Vo  distinction  as  to  the  geograph¬ 
ical  scope  of  the  network  is  made  because  it  does  not  impact  the 
taxonomy  considerations  addressed  here. 


Uses  of  a  Taxonomy 


The  derivation  of  a  meaningful  taxonomy  in  any  context  is 
dependent  upon  the  intended  use  of  the  classification  scheme.  If 
the  resulting  taxonomy  is  intended  to  succinctly  convey  certain 
attributes  of  the  entities  classified  then  the  appropriate  nota¬ 
tion  should  no  doubt  be  founded  upon  the  most  important  attri¬ 
butes  of  the  various  entities.  Typically  the  use  of  taxonomies 
is  static  in  nature,  that  is,  there  is  no  particular  emphasis 
upon  the  dynamics  of  the  classification  mechanism  itself. 

In  some  contexts  the  dynamics  of  the  classification  process 
is  an  important  aspect  of  the  taxonomy  scheme.  For  example  it 
may  be  important  to  quickly  classify  an  entity  into  the  correct 
class.  This  contrasts  to  the  usual  usage  of  a  taxonomy  (such  as 
in  biology)  where  the  taxonomy  is  used  only  to  infer  the  attri¬ 
butes  of  the  entity  based  uoon  its  classification.  The  former  is 
a  dynamic  process  involving  decision  making  at  several  levels; 
the  latter  is  a  decoding  process  based  uoon  the  taxonomy  nota¬ 
tion. 

Thu3  a  taxonomy  may  be  viewed  as  useful  in  two  complementary 
ways:  in  one  instance,  given  an  unknown  entity,  classify  it 
correctly  by  making  a  series  of  multivalued  decisions  based  upon 
the  entity's  important  (and  discoverable)  attributes;  in  the 
other  instance,  given  a  set  of  attributes  of  interest,  discover 
the  appropriate  class  of  entities  by  making  a  series  of 
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multivalued  decisions  based  uoon  the  attributes.  Here  we  use 
’attributes'’  to  mean  any  property  of  the  entity  of  interest;  in 
the  network  taxonomy  context  example  attributes  are  fault  toler¬ 
ance  and  communications  topoloqy.  A  design  procedure  could 
clearly  benefit  from  the  latter  view  of  a  taxonomy. 

In  particular,  a  correctly  defined  taxonomy  will  be  useful, 
and  even  possibly  essential,  in  a  design  orocedure  for  translat¬ 
ing  a  set  of  network  requirements  into  the  ’’best"  network  confi¬ 
guration  satisfying  those  requirements.  To  be  useful  in  this 
manner  the  designer  must  know  how  to  measure  each  of  the  criteria 
used  in  the  classification  scheme,  have  available  an  objective 
function  which  combines  the  various  attributes  in  a  way  appropri¬ 
ate  to  the  network  user's  intentions  and  such  that  maximizing  the 
functional  value  is  tantamount  to  finding  the  "best'*  network. 

In  summary,  a  network  taxonomy  must  be  amenable  to  a 
sequence  of  multivalued  decisions,  each  of  which  is  based  upon  a 
measurable  criteria  aopropriate  to  the  user  requirements,  such 
that  each  decision  stage  successively  prunes  the  solution  space 
in  an  optimal  way  until  a  single,  best  network  topology  remains. 
Codification  of  this  decision  procedure  would  constitute  the 
creation  of  a  very  useful  and  desirable  design  method.  Unfor-* 
tunately  the  knowledge  is  not  presently  available  to  permit  a 
definitive  design  method;  much  research  remains  to  be  accom¬ 
plished  before  any  universally  acceptable  design  orocedure  can  be 
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found . 


This  paper  is  primarily  concerned  with  the  derivation  of  a 
taxonomy  useful  in  the  manner  described.  To  meet  this  goal, 
requirements  important  to  the  network  user  are  reviewed,  the 
specification  of  an  objective  function  is  reviewed,  and  then  an 
analysis  of  a  particular  taxonomy  is  presented,  extensions  pro¬ 
posed,  and  conclusions  drawn. 

Network  Requirement  Speci f icat ion 

In  this  section  the  specification  of  network  requirements  is 
reviewed.  An  understanding  of  these  requirements  is  necessary  to 
the  development  of  a  taxonomy  useful  to  a  design  method  that 
translates  those  requirements  for  a  given  application  into  a  best 
network  topology. 

kaczmarek  and  NcGreqcr  [Kacz731  provide  an  excellent  summary 
on  the  definition  of  the  networking  problem  to  be  solved.  They 
state  that  requirements  are  of  two  tyoes:  strategical,  to  pro¬ 
vide  scope  and  direction  to  the  development  of  a  solution  space? 
and  tactical ,  which  governs  the  actual  development  of  a  solution. 
These  tyoes  are  categorized  as  qualitative  and  quantitative  needs 
and  desires,  respectively. 

Strategical  requirements  are  classed  as  guidelines  (neces¬ 
sary  attributes  of  an  acceptable  solution)  ,  data  processing  fac¬ 
tors  (possible  evolutionary  oatterns  of  communication  carried)  , 
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and  issues  and  oriorities  (unresolved  factors  possibly  impacting 
the  strategy) .  Tactical  requirements  are  the  environment  (loca¬ 
tion  of  user  nodes)  ,  data  movement  requirements  (message  charac¬ 
teristics  and  timing),  performance  (level  of  service  provided), 
and  node  interface  requirements  (user  to  network  nrotocol) . 
Judgement  as  to  the  necessity  or  completeness  of  these  require-* 
ments  is  not  made  here;  rather  we  accept  these  network  require¬ 
ments  as  a  basis  upon  which  to  discuss  the  role  of  a  network  tax¬ 
onomy  scheme  in  a  design  method. 

Suppose  a  user  of  a  potential  network  has  somehow  generated 
a  set  of  requirements  of  the  tyoe  suggested  above.  The  geograph¬ 
ical  locations  of  nodes  are  stated,  the  properties  of  the  mes¬ 
sages  estimated  (arrival  rates,  message  lengths,  source- 
destination  statistics) ,  and  a  user-to-network  orotocol  has  been 
established.  Can  a  design  method  translate  these  system  require¬ 
ments  into  a  best  network  topology?  The  answer  is  ”00”  because  a 
measure  ot  what  constitutes  "best"  has  not  yet  been  provided.  An 
"objective  function"  is  needed  that  can  be  used  to  rank  order  the 
alternate  network  configurations  by  providing  a  single  measure 
acceptable  to  the  network  user.  The  next  section  discusses  the 
nature  of  an  objective  function  in  the  network  design  context. 

Objective  Function  Specification 

The  definition  of  the  particular  application  tor  which  a 
network  is  being  designed  must  be  complete  enough  to  indicate  the 
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relative  importance  of  the  strategical  and  tactical  requirements 
in  a  functional  form.  This  function  can  be  described  as  an 
"objective  function"  because  it  maps  values  of  a  set  of  indepen¬ 
dent  variables  (amount  of  each  requirement  currently  provided) 
into  a  single  dependent  value.  This  dependent  value  is  to  be 
maximized  (by  definition)  ,  and  hence  describes  the  "objective"  of 
the  optimization  process. 

It  is  often  the  form  of  the  objective  function  (and  possibly 
of  the  constraints  upon  the  independent  variables)  that  provides 
a  basis  for  an  algorithm  for  deriving  the  optimal  values  of  the 
independent  variable;  the  linear  programming  problem  is  an  exam¬ 
ple  of  this  circumstance.  It  is  unknown  if  the  network  design 
problem  can  be  formulated  in  a  manner  such  that  an  existing  algo¬ 
rithm  is  applicable. 

Some  research  on  network  measures  has  been  accomplished. 
Ponzalez  and  Jordan  [Son79]  have  developed  a  framework  for  the 
quantitative  evaluation  of  distributed  computer  systems.  They 
define  a  dimensionless  "figure  of  merit"  as  a  weighted  sum  of  the 
difference  between  the  desired  and  actual  amount  of  each  of  a  set 
of  attributes.  They  also  present  an  analysis  pertaining  to  the 
form  of  the  weighting  and  to  the  effect  of  adding  or  deleting 
attributes.  In  particular  they  propose  an  aporoach  that  relates 
the  figure  of  merit  to  a  set  of  "functional  primitives"  that  are 
common  to  all  alternate  designs.  Examples  of  primitives  are 


basses,  processor  and  memory  cycle  time,  communication  protocols, 
and  arbitration  schemes.  This  seems  to  be  a  Promising  approach: 
what  remains  is  to  identify  network  attributes  pertaining  to  the 
user  requirements,  the  derivation  principles  for  the  attribute 
weights,  and  the  definition  of  the  3}o0%=9al  primitives  --  hence 
only  a  framework  is  presented  by  Gonzalez  and  Jordan. 

Several  authors  have  proposed  definitions  of  the  independent 
variables  that  constitute  the  set  of  attributes  needed  for  an 
objective  function.  Generally  they  consist  of  performance  (a 
throughout  measure) ,  cost  and  place  modularity,  failure  effect, 
switching  complexity,  reconfiguration  potential  ( extamsiu>  il  itv> 
d?ntee  of  security  or  integritv ,  maintainability,  and  present 
value  of  system  life  cycle  cost.  These  are  discussed  in  detail 
in  f Ghou74 1  and  (G r ubb7S 1  ,  the  latter  being  a  definition  of  nine 
performance  evaluation  criteria  recommended  by  the  National 
bureau  of  Standards.  McGregor  and  Kaczmarek  [McG7Sl  describe  in 
detail  the  criteria  used  in  a  network  model  used  by  the  Network 
Analysis  Corporation. 

If  an  objective  function  includes  a.  mechanism  for  mapping 
network  attributes  into  functional  primitives  then  the  determina¬ 
tion  and  definition  of  these  primitives  is  an  important  task 
necessary  to  a  network  design  method.  In  the  next  section  a  set 
of  hardware  interconnection  primitives  is  defined. 


The  Hardware  Interconnection  Primitive  Set 

Because  of  the  nature  of  digital  hardware  a  basic  set  of 
hardware  interconnection  primitives  (HIPs)  may  be  defined.  From 
this  set  any  functionally  representative  computer  network  inter¬ 
connection  subsystem  (IBS)  can  be  constructed  when  the  IBB  is  a 
primary  mechanism  which  influences  the  operational  attributes  of 
a  network  rcarey79],  A  later  section  discusses  the  ability  of  a 
oarticular  taxonomy  to  adequately  describe  ISBs  of  interest. 

Table  1  summarizes  eleven  functionally  distinguishable  HIps 
needed  to  construct  a  functionally  representative  set  of  computer 
networks.  Part  (a)  of  Table  1  indicates  those  HIPs  that  may 
exist  in  serial  or  parallel  versions.  The  second  grouo  (b)  indi¬ 
cates  three  other  HI^s  that  can  be  in  anv  of  several  forms  and 
group  (c)  indicates  necessary  but  functionally  passive  HIPs  that 
do  not  affect  the  architecture  of  a  computer  network. 

Hore  detailed  information  on  these  various  HIPs  is  oresented 
in  a  succinct  form  in  Table  2.  The  exact  physical  implementation 
of  these  HIPs  is  unimportant  here;  rather  we  concentrate  upon  the 
function  of  each  HIP  in  the  computer  network  context.  Each  HIP 
embodies  characteristics  of  and  the  functionality  of  hardware 
components  used  in  existing  computer  networks;  for  example  see 
[HcCoyBTl . 
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Table  1.  Rasic  set  of  HIPs  from  which  the  various 
Network  architectures  can  be  constructed. 


(a)  Tyne  1  HIPs  having  both  serial  and  parallel  versions 


BIU 

LIU 

'J\n 

SWn 

L 


bus  interface  unit 
loop  interface  unit 
user  adapter,  n  users 
switch,  any  two  of  n  ports 
link 


(b)  Type  7  HIPs  can  be  in  any  of  several  forms 


CD  communications  processor 

BV  bus  window 

B  bus 

H  memory 


(c)  Tyne  3  HIPs  that  are  functionally  passive 

BR  bus  repeater 

BT  bus  terminator 


h  number  of  specific  IBBs  may  be  examined  within  the  con¬ 
text  of  the  ’Vnderson  and  lensen  f\nder75]  classifications.  Fig¬ 
ure  1  shows  a  loop  network  (ObL  in  the  M  taxonomy)  constructed 
from  the  LIU  HIPs  described  above.  Bach  IBB  is  Presented  using 
the  PMS  notation  (Bell7l1.  Figure  1(a)  shows  a  four  node  DDL 
network  consisting  of  LIUs  and  links  (the  Ls) .  The  unterminated 
lines  projecting  from  the  LIUs  are  ports  to  user  node  components 
not  shown  because  they  are  not  logically  part  of  the  network 
proper.  Figure  1(b)  illustrates  how,  in  some  network  configura¬ 
tions,  a  'J\4  H I °  may  be  used  to  interface  more  than  one  user  pro¬ 
cessor  to  the  loop. 
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Table  7.  Definition  of  Hardware  Interconnection  Primi¬ 
tives. 

Tyne  1  HIPs 


BIU  -  Bus  Interface  Unit.  Interfaces  a  serial/parallel 
link  to  a  bus;  the  link  side  is  assumed  to  conform 
to  the  bus  protocol;  minimal  intelligence  and 
buffering  capability;  typically  interfaces  a  bus 
with  a  ser  ial/parallel  link;  an  'J\n  HIP,  a  BWn  HIP, 
a  B w  HIP,  or  a  CP  HIP;  failure  does  not  effect  the 
bus . 

LIU  -  Loop  Interface  Unit.  Interfaces  a  serial/parallel 
link  to  a  loop  type  architecture;  there  is  enough 
buffering  capability  to  store  several  incoming  or 
outgoing  packets;  only  a  sending  LI'J  can  remove  a 
packet  from  the  loop;  a  receiving  LIU  marks  a  pass¬ 
ing  packet  as  "received',  copies  it  into  a  buffer, 
and  sends  the  packet  on;  capable  of  synchronizing 
itself  with  other  LIUs;  typically  interfaces  to  an 
'An  or  a  CP  HIP;  failure  disables  the  entire  loop. 

'JAn  -  User  Adapter,  n  users.  Interfaces  n  users  to  a 
serial/  parallel  port;  acts  as  a  specialized  switch; 
failure  typically  isolates  the  n  users  from  the  net¬ 
work. 

SWn  -  Switch,  n  Ports.  Connects  any  two  of  n 
ser ial/parallel  ports  for  the  duration  of  packet 
transmission;  has  enough  intelligence  to  make  a  con¬ 
nection  based  uoon  destination  address  (based  ucon 
routing  tables);  some  buffering  capability;  act  as  a 
specialized  CP  HIP;  failure  results  in  all  links 
beinc  blocked. 


Figure  2  shows  a  completely  interconnected  star  configuration 
call  DOC  in  the  AJ  taxonomy.  In  Figure  2(a)  a  four  node  network 
is  shown  composed  of  BW4  HIPs.  Again  a  user  adapter  HIP  could  be 
used  to  interface  more  than  one  user  processor  to  a  node  if  that 
were  desirable.  If  a  five  node  DOC  network  is  to  be  constructed 
it  could  be  made  from  ’'larger'’  switches,  say  a  SW5,  or  it  could 
be  made  from  cascading  together  more  than  one  "smaller"  switch. 


Table  2  continued 
Tyoe  2  4 IPs 


CP  -  Communications  Processor.  General  intelligence  to 
interface  several  serial/parallel  ports  to  each 
other;  requires  a  microprocessor;  could  be  special¬ 
ized  via  programming  to  oerform  a  wide  variety  of 
functions;  failure  blocks  all  communication  between 
the  ports. 

L  -  Link.  Communications  medium;  contains  no  intelli¬ 
gence;  may  contain  "boosters"  to  extend  its  effec¬ 
tive  length;  may  be  serial/parallel;  failure  breaks 
communication  between  the  end  ooints  of  the  link. 

BW  -  Bus  Window.  Interfaces  two  internal  busses  when 
memory  addresses  indicate  the  necessity;  in  general 
allows  the  busses  to  operate  independently;  no 
buffering  capability;  failure  isolates  the  two 
busses. 

B  -  Bus.  Implements  the  set  of  signal  lines  used  by  an 
interface  system  to  which  a  multiplicity  of  devices 
are  connected  and  over  which  messages  are  carried 
(1155575];  typically  a  higher  bandwidth  than  a  link; 
failure  isolates  all  BI'Js  and  stoos  all  communica¬ 
tion. 

M  -  Memory.  May  be  multioort;  interfaces  to  a  bus  via  a 
bus  interface  unit;  failure  effect  depends  upon  the 
parity/errot  correction  scheme  used. 


as  shown  in  part  (b) .  In  the  particular  case  one  of  the  ports  of 
the  SW4s  in  not  used  because  it  is  not  needed.  Figure  3  shows  a 
shared  memory  or  DSM  network.  Users  would  interface  with  the 
opposite  ends  of  the  links.  Fiqure  4  shows  a  shared  bus  network 
with  two  bus  interface  units  or  BIUs;  one  has  a  user  adapter 
attached.  Figure  5  shows  a  single  SW4  BIP  used  as  the  hub  of  a 
central  star  ICDS  network.  Again  either  a  larger  switch  (ie,  a 
SW5)  or  cascaded  switches  could  be  used  for  the  construction  of  a 
ICDS  network  of  more  nodes. 


Table  2  continued 
Tyne  3  HIPs 


BR  -  Bus  Repeater.  Provides  a  boost  in  signal  strength  to 
allow  a  physical  extension  of  a  bus;  failure  results 
in  the  isolation  of  the  bus  components  from  each 
other . 

BT  -  Bus  Terminator.  Prevents  reflections  from  the  ends 
of  a  bus;  failure  reduces  the  effective  bandwidth;  a 
passive 


A  loop  with  central  switch  is  shown  in  Figure  *>.  Note  the  LI'J 
RIP  is  used  as  in  the  DOL  loop,  but  here  the  communications  pro¬ 
cessor  HIP  (a  CP)  is  employed  to  effectively  produce  an  "intelli¬ 
gent  LIU".  Similarly  Figure  7  shows  a  bus  with  central  switch;  a 
CP  HIP  is  interfaced  to  the  bus  by  a  BI'J.  User  processes  would 
be  attached  to  the  other  BIUs. 


figure  3  shows  an  example  of  a  five  user  node  irreqular  net¬ 
work  ( I DPI )  composed  from  SW4s.  Mote  three  of  the  SW4  are 
underutilized.  Figure  9  shows  two  direct  shared  bus  networks  (as 
in  Figure  4)  interconnected  by  a  bus  window  HIP.  Fiqure  10  shows 
an  inOR  "regular"  network  made  from  SW5  HIPs.  A  variation  ot 
this  using  busses  is  shown  in  Figure  11;  the  MICRONST  network 
(Witt79)  is  an  example  of  an  "IbHR"  classification  which  was  not 
included  in  the  original  AJ  classification. 


In  this  section  we  have  defined  a  set  of  hardware  intercon¬ 


nection  primitives  and  exhibited  their  use  in  a  variety  of  net¬ 
work  configurations.  The  usefulness  of  these  HI»s  in  a  design 
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Figure  1 


LIU 


LIU 


A)  DDL  network  with  four  nodes 


UA4 


l 

I 


B)  Detail  of  a  single  DDL  node  made  to 
adapt  up  to  four  user  processes  by 
means  of  a  UA4  HI? 


A  DDL  network  built  from  the  basic  set  of  HIPs. 
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A)  Four  node  DDC  "star"  network  built 
from  completely  utilized  SW4  HIPs. 


\ 


SW4 - 3W4 


B)  Detail  of  a  single  node  of  a  five 
node  DDC  star  networ.c.  Note  how 
the  SV/4  HIP  on  the  right  Is  under¬ 
utilized  . 


Figure  2  Examples  of  DDC  "star"  networks  built 
from  the  basic  HIP  set. 


FT'SY 
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Figure  3  An  example  of  a  DSM  network.  User 
processes  In  the  computers  (Cs) 
interface  with  the  links  (Ls). 

\\/y 

.  UA4 

I  t 

B1U  BIU 


Figure  4  A  DSB  network  with  one  single  user 
node  and  another  node  supporting  up 
to  four  users. 


Figure  5  A  lODS  central  star  network. 


Figure  o  Ar.  I  CD!  .co;  wit.-,  central  switch 
r.etwor.. . 


BIU  BIU  BIU 


Figure  7  An  IC3E  "bus  with,  central  switch" 
network. 


Figure  8  An  IDDI  "irregular  network  with  six 
user  r.  des . 


Figure  11  An  IDSR  "ir.icronet"  network. 


i 
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method  using  the  objective  function  ideas  of  Gonzalez  and  Jordan 
is  unknown;  the  definition  of  a  useful  taxonomy  is  a  prerequisite 
to  an  answer.  In  the  next  section  the  Anderson  and  Jensen  taxon¬ 
omy  alluded  to  above  is  examined  from  this  point  of  view. 

The  Anderson  and  Jensen  Taxonomy 

In  this  section  the  Anderson  and  Jensen  taxonomy  [Ander751 
is  reviewed  because  of  its  apparent  usefulness  as  a  base  fot 
classifying  network  architectures.  It  nay  also  be  extended  to 
realize  a  mere  complete  taxonomy  uoon  which  to  base  a  network 
design  methodology.  Its  underlying  basis  is  examined  and  an 
analysis  of  its  strengths  and  weaknesses  concerning  its  potential 
role  in  an  attribute/functional  primitive  driven  design  method  is 
made. 


Anderson  and  Jensen  (AJ)  view  a  network  as  a  message  passing 
medium  with  the  hardware  units  forming  the  interconnection  struc¬ 
ture  of  a  computer  network  as  the  basis  of  a  taxonomy.  In  par¬ 
ticular  the  hardware  components  of  interest  are  paths  and 
switches,  as  well  as  user  nodes.  A  oath  is  the  medium  over  which 
a  message  packet  is  carried  between  processing  nodes,  and  a 
switch  is  the  intelligence  along  an  indirect  oath  between  sender 
and  receiver.  Thus  the  hardware  components  are  user  orocessing 
nodes,  paths,  and  switches. 

A  system  architecture  may  then  be  characterized  by  the 
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interconnection  of  these  hardware  components.  AJ  state  that  four 
levels  ot  stages  of  decision  making  are  adequate  to  classify  the 
different  ways  in  which  the  hardware  components  can  be  intercon¬ 
nected,  and  hence  a  tree  structure  can  be  used  to  represent  the 
taxonomy.  Figure  12  shows  the  AJ  taxonomy  tree.  From  the  top 
level  down  the  decisions  concern  message  packet  transfer  strategy 
(direct  or  indirect),  message  packet  transfer  control  method 
(none,  centralized,  or  decentralized)  ,  transfer  path  structure 
(dedicated  or  shared)  ,  and  finally  a  decision  as  to  the  the  final 
network  topology. 

The  usefulness  of  the  AJ  taxonomy  in  a  network  design  pro¬ 
cedure  depends  upon  the  ability  to  relate  the  four  levels  of 
decision  to  the  original  design  requirements.  Exactly  how  the 
design  requirements  translate  directly  or  easily  into  a  decision 
on,  say,  message  packet  transfer  strategy  is  not  immediately 
clear.  It  may  be  that  other  decisions  can  be  made  directly  (and 
early  on)  from  user  requirements  that  have  the  identical  effect 
of  pruning  the  tooological  solution  soace. 

Several  computer  network  topologies  do  not  fit  smoothly  into 
the  AJ  taxonomy.  Various  hybrids  of  the  basic  ten  topologies  can 
exist.  These  may  be  in  the  form  of  hierarchical  networks  such  as 
RHEA  fPow7S] ,  or  just  coincidental  networks  interconnected  by  a 


'gateway''  [hav79].  As  mentioned  earlier  the  MICROMET  network 
forms  a  new  leaf  in  the  AT  taxonomy  tree  which  may  be  termed  an 
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Ib<5R  type  network.  Component  redundancies  tor  fault  tolerance 
are  not  expressible  in  the  AJ  taxonomy,  nor  are  any  aspects  of  a 
network  protocol. 

In  summary,  the  AJ  taxonomy  may  be  incomplete  and  even  inap¬ 
propriate  for  the  design  orocedure  environment  but  seems  to  pro¬ 
vide  the  best  conceptual  structure  at  this  time.  The  next  sec¬ 
tion  addresses  those  attributes  necessary  in  a  taxonomy  from  the 
design  procedure  viewooint. 

The  Completeness  of  the  AJ  Taxonom y 

In  this  section  we  examine  the  completeness  of  the  AJ  taxon¬ 
omy  with  regard  to  the  fundamentally  unique  network  topologies. 
Recall  that  Aj  define  a  'svstem  architecture"  level  beneath  three 
other  layers  of  decision  concerning  transfer  strategy,  transfer 
control  method,  and  transfer  control  structure.  At  the  thir^ 
level  there  exists  three  sets  of  dedicated  oaths  an-1  shared  o=th 
oairs,  the  maximum  provided  by  the  decision  alternatives  allowed. 
From  these  six  oossibil ities  AJ  define  ten  system  architectures. 
It  may  be  that  other  possibilities  exist  as  was  indicated  by  the 
Micronet  system. 

The  first  of  the  six  transfer  oath  structure  possibilities 
is  the  OOx  grouping  that  is  subdivided  into  the  not,  and  00C  clas¬ 
sifications.  Clearly  the  DOL  is  the  minimal  way  of  connecting  a 
given  number  of  nodes  in  the  Dbx  context  and  the  ODC  is  the  maxi- 
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mal  way  of  ccnnectim  a  set  of  nodes.  It  aooears  that  adding  more 
paths  to  the  00L  network  or  removin'?  some  paths  from  the  ODC  net¬ 
work  adds  nothing  significant  in  the  way  of  system  architecture. 
Such  intermediate  network  types  could  be  appropriately  classified 
as  an  inoi  "irregular",  hence  this  group  is  complete. 

The  second  grouping  is  the  OSx  set,  resulting  in  the  OSM  and 
DSS  architectures.  The  distinguishing  point  here  is  the  inclu¬ 
sion  of  memory  as  the  path  or  not;  note  the  bus  behaves  only  as  a 
temoorary  memory  device.  Mere  again  the  two  subclasses  are 
exhaustive,  and  so  no  new  unique  architecture  can  exist. 

The  ICOx  grouping  is  next;  it  results  in  the  ICOS  "star”  and 
the  ICOL  "loop  with  central  switch"  subtypes.  By  definition  mes¬ 
sages  are  sent  to  the  switch  and  then  retransmitted  to  their 
final  destination.  Within  the  ICO  systems  it  seems  that  only  the 
two  possibilities  can  exist,  and  so  this  grouping  is  complete. 

Only  one  architecture  for  the  ICS  grouping  is  defined  by  A7. 
This  "bus  with  central  switch"  architecture  seems  unique  in  that 
all  the  shared  path  types  rely  on  a  bus,  and  a  centralized  rout¬ 
ing  switch  can  be  included  in  only  one  way;  hence  this  class  is 
complete.  The  definition  of  a  switch  in  this  classification 
seems  too  restrictive.  A  centralized  bus  arbitration  scheme 
might  be  allowed  in  the  ICS  group,  even  though  the  message  might 
be  sent  directly  to  the  receiving  node  without  retransmission. 
This  apr.»ars  to  follow  from  AJ '  s  definition  of  a  switch  as  "the 


intervening  intelligence  between  sender  and  receiver".  Thus  a 
coiling  scheme,  such  as  used  in  SHIM»ADs  [kuhns791  ,  'night  be  per¬ 
mitted  in  the  ICS  classification. 

The  fifth  group,  IDPx ,  is  subdivided  into  "regular"  and 
"irregular”,  clearly  an  exhaustive  set.  Thus  this  group  seems 
complete . 

The  last  group  is  InSx,  consisting  of  the  one  classification 
I OS  "bus  window".  In  general  this  permits  an  irregular  structure 
of  busses.  Since  at  least  one  "regular"  network  of  the  I OS  type 
is  described  in  the  literature  a  second  subclassification  within 
this  group  should  be  defined,  namely  an  "loss"  type.  The  network 
described  by  this  class  is  wittie*s  micsomtt  C™itt791.  To  our 
knowledge  this  is  the  only  non-hvbrid  network  found  in  the 
literature  requiring  another  system  architecture  within  the  A7 
framework . 

In  summary,  an  analysis  of  the  A.7  taxonomy  in  terms  of 
experimental  networks  indicates  only  one  new  system  architecture 
exists,  given  the  manner  used  to  define  the  subclassifications; 
otherwise  each  group  is  divided  into  exhaustive  classes,  based 
upon  some  criterion  such  as  interconnection,  memory  capability,  a 
switch,  regularity,  or  interconnection  device  type,  we  conclude 
that  as  tar  as  basic  classifications  are  concerned  the  A.7  taxon¬ 
omy  is  adequate,  given  the  premise  upon  which  it  is  based. 
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Attr ibutes  of  a  Oesign  Oriented  Taxonony 

In  this  section  a  basis  for  a  network  taxonomy  amenable  to 
an  attribute/functional  primitive  driven  design  method  is 
presented.  The  primary  emphasis  is  placed  upon  the  topological 
selection  criteria;  it  may  be  that  other  considerations  would 
influence  the  development  of  a  taxonomy  in  other  ways. 

A  useful  taxonomy  in  a  design  environment  should  address  the 
strategical  aspects  of  a  network  tooologv  critical  to  the  network 
user.  Examples  of  these  aspects  are  the  ability  of  a  network  to 
transmit  the  current  and  future  message  Packet  lead;  that  it  be 
maintainable  and  extensible,  that  it  be  fault  tolerant  to  the 
degree  desired;  that  it  be  place  and  cost  modular  with  resoect  to 
the  addition  of  future  node  sites;  and  that  it  be  least  expensive 
in  terms  of  present  value  of  life  cycle  cost.  The  main  problem 
is  to  identify  all  the  criteria  that  relate  to  topolon ical  deci¬ 
sions,  relate  them  to  user  requirements,  determine  their  relative 
importance  to  each  other,  and  express  the  sequence  of  decisions 
in  such  a  manner  that  the  topological  solution  space  is  quickly 
pruned . 

One  approach  to  deriving  such  a  taxonomy  is  to  configure  the 
possible  computer  networks  given  a  set  of  T?lPs,  identify  the 
resultant  network  attributes  in  relation  to  user  requirements, 
and  then  to  derive  an  appropriate  sequence  of  decisions.  This 
might  be  called  a  "bottom  up"  approach.  A  "too  down”  approach 
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might  be  to  identity  the  relationships  between  user  requirements 
and  decisions  affecting  network  topology,  making  sure  the  deci¬ 
sions  are  answerable  in  terms  of  user  requirements.  The  latter 
approach  is  more  applicable  to  a  design  procedure,  and  so  is  pur¬ 
sued  here. 

The  question  is  what  user  requirements  relate  to  the  highest 
level  of  network  topological  decision  making.  Clearly  geographi¬ 
cal  considerations  are  one  component  in  the  highest  level 
category.  For  example  a  network  covering  a  large  geographical 
area  is  most  likely  to  be  of  an  "irregular”  nature  just  to  keep 
interconnection  costs  reasonably  low.  However  this  need  not  be 
necessarily  so:  given  aopropriate  traffic  character istics  a  radio 
medium  based  network  (such  as  ALOHA  [Abram?0)  ,  or  a  satellite  to 
user  network)  may  be  the  least  expensive  in  interconnection 
costs.  Still,  certain  topologies  might  be  excluded,  such  as  loop 
or  bus  based  networks,  so  geographical  disoersement  may  be  useful 
at  a  high  level  in  a  design  procedure.  If  that  is  the  case  should 
the  design  decision  be  stated  in  terms  of  "message  transfer  stra¬ 
tegy"  (as  it  is  in  the  AJ  taxonomy)  or  some  other  statement 
closer  to  the  requirements  of  the  design  problem? 

Performance  measures  have  the  same  type  of  problems.  Given 
a  performance  measure  (for  example,  messages  oer  second)  how  does 
a  designer  infer  a  topological  conclusion?  The  problem  here  is 
that  any  topology  could  theoretically  be  made  to  carry  any  mes- 
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sage  load,  given  approoriate  technology.  It  may  be  that  the 
functional  primitives  (HIPs  in  particular^  could  provide  guidance 
in  this  area.  The  cost  per  bandwidth  unit  will  be  a  step  func¬ 
tion  in  a  building  block  design  environment,  hence  matching  per¬ 
formance  to  HIP  may  infer  decisions  about  applicable  ISSs  and 
therefore  network  topologies. 

The  next  section  examines  the  possibility  of  extending  the 
basic  AJ  taxonomy  to  include  redundant  HIPs  for  fault  tolerance 
purposes. 

Taxonomy  Extensions  for  Fault  Tolerance  Considerations 

An  additional  important  consideration  is  the  extension  of 
the  basic  AJ  taxonomy  to  include  a  notation  to  express  the  fault 
tolerant  behavior  resulting  from  the  inclusion  of  HIP  redundan¬ 
cies.  This  tooic  is  specifically  chosen  because  of  its  impor¬ 
tance  to  network  users  and  designers.  As  the  AJ  taxonomy  now 
stands  only  the  basic  properties  of  a  particular  classification 
are  described;  additional  HIPs  that  might  be  added  for  a  specific 
purpose,  such  as  fault  tolerant  reasons,  have  no  mechanism  per¬ 
mitting  their  description. 

An  example  OSH  architecture  with  a  second,  redundant  bus  is 
shown  in  Figure  13.  Here  the  bus  interface  units  (BIUs)  are 
modified  from  the  earlier  definition  such  that  two  busses  may  be 
interfaced;  note  however,  that  they  remain  lonicallv  identical 
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functional  primitives.  Each  HIH  must  now  contain  the  ability  to 
compare  the  behavior  of  both  busses  and  to  determine  which 
behavior  is  most  likely  to  be  correct.  The  point  is  that  the 
fault  tolerant  IHS  shown  in  Figure  13  remains  a  OS'*  architecture 
because  of  its  overall  behavioral  attributes. 

Equivalent  situations  can  be  easily  formulated  for  the  other 
classes  of  networks.  DbL  loop  networks  could  be  in  ’’parallel”  if 
suitable  modifications  were  made  to  the  LUJs.  Any  of  the  "regu- 
lar”  topologies  could  he  modified  in  a  similar  manner.  Some  of 
the  basic  architectures  imbed  an  equivalent  level  of  fault  toler¬ 
ance  without  the  need  for  additional,  redundant  components.  "’or 
example,  the  micpomst  architecture  mentioned  earlier  (a  "regular" 
network  of  DSS  architectures)  already  has  the  fault  tolerant 
capabilities  of  the  duplicate  bus  DSS  described  above.  Hence  the 
HICSONST  1 1 OSH"  architecture  has  inherent  fault  tolerance  to  some 
degree,  and  so  does  not  necessarily  require  an  extension  to  the 
taxonomy  notation  to  express  this  fact.  Thus  the  explicit  refer¬ 
ence  to  a  duplicated  HIP  component  does  not  seem  to  be  a  good  way 
to  express  a  level  of  fault  tolerant  capability. 

Another  approach  to  expressing  a  fault  tolerant  capability 
might  be  to  determine  the  types  of  effect  a  single  component  HIP 
failure  may  cause.  This  may  be  called  a  "failure  effect"  way  of 
describing  fault  tolerance,  in  contrast  to  a  component  oriented 
notation.  For  example,  in  the  duplicated  bus  DHH  configuration 
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we  could  state  that  a  failure  of  one  of  the  two  busses  would 
cause  no  loss  of  communication  between  user  nodes.  Still,  the 
failure  of  another  HIP ,  say  the  BIU  in  this  case,  might  isolate 
the  user  orocesses  attached  to  it  but  not  affect  the  communica¬ 
tion  between  the  remaining  user  processes.  Thus  at  least  two 
major  failure  effect  modes,  loss  of  node  and  loss  of  network, 
must  be  resolved.  This  implies  that  the  particular  type  of  com¬ 
ponent  HIP  that  fails  must  be  taken  into  consideration  in  a  use¬ 
ful  notation. 

Given  the  situation  described  above  it  seems  appropriate  to 
define  classes  of  fault  tolerance  suitable  to  describe  the  effect 
of  its  failure.  Thus  positional  notation  could  be  used  to  indi¬ 
cate  the  type  of  HIP  failure,  and  encodings  in  each  oosition 
could  be  defined  to  indicate  its  failure  effect.  A  two  component 
encoding  is  therefore  proposed,  both  of  which  indicate  a  failure 
effect  of  a  class  of  HIPs.  The  first  component  of  the  pair 
relates  to  the  failure  of  an  interface  HIP,  and  the  second  com¬ 
ponent  of  the  pair  to  the  failure  of  a  communication  path  HIP  (a 
link  or  switch).  Encodings  for  the  effect  must  be  descriptive, 
succinct,  and  easily  remembered;  we  suggest  ”T''  for  tolerant,  "L" 
for  localized,  and  "V"  for  vulnerable.  Table  3  indicates  the 
definition  of  these  encoding  in  more  detail. 

Gertainly  more  detail  could  be  included  into  the  notation  but  it 
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Table  3.  Effect  Encodings. 

Encoding  Failure  Effect 

T  Tolerant  fault  effect  behavior. 

Failure  means  no  loss  of  network 
capability. 

L  Localized  fault  effect  behavior. 

Failure  means  only  locally  attached 
user  processes  are  isolated  from 
the  remaining  processes. 

V  Vulnerable  fault  effect  behavior. 

Failure  means  the  entire  network 
becomes  inoperative. 

would  be  of  little  additional  value  to  a  reader  interested  in  the 
particular  fault  tolerant  behavior  of  the  network?  other  nota- 
tional  schemes,  such  as  a  graphical  representation  of  the  net¬ 
work,  could  provide  implementation  details  to  a  reader,  if  addi¬ 
tional  detail  were  needed. 

The  notation  proposed  is  the  use  of  the  PMS  notation  of  Bell 
and  Mewell  [Bell711  in  which  attributes  of  a  system  are  enclosed 
in  square  brackets.  In  this  context  the  first  entry  is  the  VJ 
classification  code,  the  second  entry  codes  the  effect  of  an 
interface  HIP  failure  and  the  third  codes  the  effect  of  a  oath 
HIP  failure: 

:=  f<class  ccde> ?  < f a i  1  ur  e  cc^e>;  <fa ilure  code>l 
where  each  < failure  code>  is  a  "T* ,  "L",  ot  a  "V". 

The  worth  of  the  proposed  extension  to  the  basic  kJ  classif¬ 
ication  scheme  can  best  be  demonstrated  by  some  examoles. 
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Consider  the  duolicated  bus  ns*?  architecture  of  Figure  13;  in  the 
prooosed  notation  it  could  be  described  as  simply  053  (if  its 
fault  tolerant  behavior  was  not  important)  or  as  .  The 
"L"  refers  to  the  local  effect  of  a  Bill  failure  and  the  ”T” 
refers  to  the  tolerant  behavior  in  the  face  of  a  single  bus 
failure.  An  ordinary  DSB  architecture  (without  a  duolicated  bus) 
could  be  classified  as  a  (nSB;L;Vl.  Similarly  there  could  exist 
a  (0DL;L;Tl.  Figure  14  shows  an  obvious  configuration  for  a 
(DPL/L/Tl  and  Figure  15  shows  another  equivalent  version.  The 
notation  proposed  here  does  not  distinguish  between  the  two  ver¬ 
sions  (because  their  fault  tolerant  behavior  is  identical)  ,  hence 
implementation  details  are  not  explicitly  indicated. 

MICROMST  could  be  classified  as  an  IbSH  or  as  an  [IOSBjLfTl 
without  regard  to  the  presence  of  MIP  redundancies.  Similarly  a 
noc  "complete"  architecture  could  be  classified  as  a  (P0C;L;Tl 
without  HIP  redundancies.  The  situation  of  the  I^hl  "irregular’ 
networks  in  not  so  clear.  For  user  nodes  connected  in  a  minimum 
scanning  tree  manner  (fewest  number  of  links  possible)  a  path 
failure  could  isolate  (in  general)  more  than  one  node’s  user 
processes  from  the  others  and  hence  would  be  an  [IPPI ;L;Ll .  If 
more  paths  existed  within  the  irregular  network  it  could  be  of 
the  class  (100I;L;TJ.  Thus  in  the  IDPI  case  redundant  HIPs  have 
a  variable  effect  on  fault  tolerance  depending  ucon  the  number 
and  placement  of  the  redundancies. 
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We  have  shown  how  path  HIP  components  may  be  configured  such 
that  a  network  may  require  a  T,  L,  or  V  encoding.  In  contrast 
all  the  examples  shown  have  had  the  first  "interface  failure 
effect"  code  a  "L"  for  a  localized  effect.  In  general  the  code 
can  become  a  "T"  only  when  an  interface  unit  is  duplicated  and 
the  same  user  processes  connected  to  both  interface  components. 
The  resulting  situation  is  that  two  nodes  now  exist  where  only 
one  existed  before,  and  so  a  larger  network  results.  Hence  the 
fault  tolerance  caoability  is  "outside"  the  network  oroper  and 
need  not  be  exolicitly  shown.  The  interface  coding  can  become  a 
"V"  only  when  a  unit  (say  a  LI'J)  failure  blocks  all  communication 
in  the  network. 

In  summary  the  notation  proposed  here  is  useful  in  describ¬ 
ing  the  fault  tolerant  effect  of  interface  unit  failures  and  path 
failures.  Three  levels  of  effect  are  provided  for  each  type  of 
failure.  More  detail  is  considered  to  be  of  little  practical  use 
and  would  result  in  a  more  complicated  encoding  scheme  than  its 
worth.  The  value  of  the  notation  scheme  proposed  has  been  demon¬ 
strated  by  several  examples. 

Taxonomy  Extensions  for  Protocols 

A  useful  taxonomy  classification  scheme  should  have  provi¬ 
sions  for  the  inclusion  of  the  description  of  an  appropriate 
level  of  protocol  because  it  conveys  the  type  of  user  terminal 
equipment  that  could  be  attached  and  something  about  the 
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performance  characteristics  of  the  network.  This  section  reviews 
the  problems  associated  with  the  development  of  such  a  notation 
and  make  a  recommendation  for  a  particular  scheme. 

A  communications  protocol  is  defined  as  those  conventions 
necessary  for  the  orooer  transmission  of  messages  over  a  network. 
Typically,  several  layers  of  protocol  are  defined  correspondinq 
to  the  various  functional  needs  involved.  An  advantage  of  con- 
siderinq  layers  of  protocols  is  that  each  functional  layer  can  be 
made  essentially  independent  of  the  other  layers,  such  that 
changes  in  any  particular  layer  need  not  affect  the  others. 
Several  definitions  of  the  various  layers  exist  in  the  literature 
and  are  germane  here.  For  purposes  of  discussion  the  Interna¬ 
tional  Standards  Organization  (ISO)  model  of  protocol  layers  is 
shown  in  Table  4  (ISO! . 

Table  4.  ISO  Protocol  Level  Vodel. 

Level  number  Function 

7  Process  control. 

S  Presentation  control. 

5  Session  control. 

(transport  mechanism) 

4  Transport  end-to-end  control. 

3  Network  control. 

2  Link  control. 

1  Physical  control. 


Of  importance  here  is  what  constitutes  the  appropriate  level  for 


inclusion  in  a  useful  taxonomy  scheme.  The  two  basic  choices  are 
at  the  "host- to-host"  level  or  the  physical/link  level. 

Consider  the  "host- to- host"  level;  this  is  the  level  that  is 
"seen"  by  the  network  user.  In  the  1*50  model  shown  in  Table  4 
the  user  sees  a  combination  of  levels  4  and  5,  which  are  con¬ 
cerned  with  both  sides  of  the  transport  medium  barrier.  Walden 
and  McKenzie  [Wald791  point  out  this  fact  as  an  indication  of  the 
possible  inappropriateness  of  the  ISO  model.  Some  other  host- 
to-host  protocols  have  been  defined:  examples  are  the  Department 
of  Defense  (the  ^panet  TCP  orotocol  and  the  ^todin  II  proto¬ 
col)  ,  the  Consultative  Committee  for  International  Telegraphy  and 
Telephony  (CCITT)  X.25  (includes  a  physical  link  level  X.21,  a 
logical  link  that  is  a  subset  of  the  HDLC  orotocol,  and  a  packet 
level  interface  protocol) ,  as  well  as  various  computer  vendors 
such  as  ISM,  DSC,  Prime,  Surroughs,  etc.  mUch  international 
effort  at  standardization  is  underway  to  define  a  true  interna¬ 
tional  standard  but  events  (like  a  de  facto  standard)  could  over¬ 
come  them  and  render  them  moot. 

\n  alternate  approach  may  be  to  concentrate  upon  the  Physi¬ 
cal  control  level  of  protocols  only,  leaving  the  higher  level  of 
interfacing  unstated.  The  problem  with  this  is  that  even  this 
level  is  not  resolved  as  to  standardization.  Still  the  issues 
are  not  as  volatile  and  at  least  one  acceptable  protocol  is 
widely  used  even  now.  This  is  the  SIh  PS-232  protocol  for  which 
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many  terminal  units  are  manufactured .  Example  of  other  Protocols 
are  X.24,  X.2S  (PS-423),  X.27  (PS-477),  and  OTP  4093;  see 
C So  1 ts79  ]  for  a  discussion  of  these  orotocols. 

Another  standardization  effort  is  currently  underway  by  the 
IEEE  (see  March  27,1930  issue  of  Electronics,  d.  40).  This 
effort  is  directed  specifically  to  local  comouter  networks;  how¬ 
ever.  they  should  have  significant  ramifications  to  computer  net¬ 
works  in  general. 

At  this  time  it  seems  aopropriate  to  define  a  notational 
scheme  for  the  host-to-host  level  in  spite  of  the  fluid  state  of 
affairs  at  this  level,  we  make  this  decision  solely  upon  its 
usefulness  to  the  potential  network  user  and  to  the  network 
designer.  This  follows  oarticularly  from  the  fact  that  a  proto¬ 
col  at  this  level  usually  implies  a  physical  level  protocol  as 
well,  although  it  need  not  do  so. 

Considering  orotocols  at  this  level  as  part  of  a  taxonomy 
classification  scheme  represents  some  risk  because  of  the  stan¬ 
dardization  ertort  versus  the  manufactures  rush  to  market  a  par¬ 
ticular  vender  unique  system.  Even  so  we  make  a  recommendation 
in  this  resnect.  The  particular  nature  of  the  recommendation 
follows  the  fotmat  of  the  optional  fault  tolerant  notation 
described  in  the  preceding  section.  As  befote  the  encodings 
should  be  succinct  and  meaningful.  Table  5  lists  some  of  the 
orotocols  currently  in  use;  other  most  likely  exist.  At  this 
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tine  no  attempt  is  made  to  encode  each  protocol  tyoe.  Instead, 
until  several  de  facto  or  true  standards  come  into  prominence  we 
suggest  that  the  full  names  shown  in  Table  5  be  used.  The  list  of 
networks  is  adapted  from  [>free79]. 


Table  5.  Protocol  Tyoes. 


Cm* 

EPIC-DPS 

LCS 

TECHNEC 

ICS 

SHIN PADS 

SPIDER 

MISS 

FIBERNET 

I  ROM 

MININET 

DNC 

DATARINC 

MITREMET 

RIT  NETWORK 

IS'Jnet 

DOM 

XNIPNET 

C.mmp 

PLURIR’JS 

AN/HS0-S7 

ARCONNE 

DCS 

CYBERNET 

DLCM 

ETHERNET 

DDLCN 

NBS 

BATNET 

PRIMENET 

HYPSRCHANNEL 

RIC 

LASL 

CERN 

labolimr 

DCTOP'JT 

X.  25 

^of  example  a  particular  network  could  be  classified  as  a 
[DEB ; ETHERNET]  .  A  fault  tolerance  field  could  also  be  apoended: 


[DSB;L;T; ETHERNET!  . 


In  summary  we  recommend  that  an  optional  appendage  indicat¬ 
ing  the  tyoe  of  host-to-host  protocol  be  made  a  part  of  a  taxon¬ 
omy  scheme.  Its  presence  would  convey  important  information  to 
the  reader,  and  would  be  useful  to  a  future  design  method,  '^e 
choose  to  use  the  commonly  accented  notations  for  the  various 
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networks  currently  used  until  that  time  true  internationally 
recognized  protocols  at  this  level  are 

Summary 

r*!e  have  reviewed  the  attributes  of  a  network  taxonomy  for  a 
design  procedure  context.  Among  the  conclusions  drawn  is  a 
determination  that  the  Anderson  and  Jensen  taxonomy  is  sufficient 
tor  characterizing  the  high  level  structures  of  networks  and 
appears  to  be  useful  as  a  base  uoon  which  to  define  extensions 
that  encompass  implementation  considerations,  fault  tolerant 
attributes,  and  communication  protocols.  Particular  extensions 
are  proposed  that  seem  advantageous  in  the  high  level  functional 
primitive  building  block  design  environment.  The  next  area  that 
must  be  studied  is  the  objective  function  area  before  a  good 
design  method  for  networks  can  be  devised.  To  some  extent  work 
on  protocol  descriptions  is  dependent  upon  international  and 
national  standardization  efforts,  in  addition  to  research  into 
protocols  themselves.  In  summary  we  believe  the  taxonomy  exten¬ 
sions  proposed  here  should  prove  to  be  of  use  in  a  future  design 
procedure  for  the  computer  network  context. 
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